perf(gc): prune the per-object layout tables from a young-entry log on a minor - #9895

…n a minor

A minor's death prune for `LAYOUT_SLOT_MASKS` + `TYPED_LAYOUTS` asked "which
owner died?" of every key in tables sized by everything the program ever
created. Both of a minor's deadness predicates require the owner to be in the
nursery — `owner_is_dead_copied_minor_from_space` demands eden or the active
survivor half, `PostTraceProbe::owner_is_dead` on a minor demands an in-arena,
untenured `HeapGeneration::Nursery` address — so an owner that was old at the
last prune is still old and the visit cannot remove anything.

Measured on a compiled claude-code streamed reply (`PERRY_GC_DIAG=1`, counter
on a measurement-only branch): 6,792,375 entries visited across 109 minor
prunes, of which at most 125,367 (1.85 %) could possibly have died; median
`young_before/visited` 0.0000; 40 of those 109 minors had NOTHING that could
have died while carrying 39 % of all visits. 54x over-visit at 3300
characters, 25x at 400. `dead <= young_before` held on 152/152 minor prunes.

So both maps take the young-entry log of PerryTS#9754 (`gc/young_log.rs`), kept in
the existing `PerObjectLayoutHint` hot slot so no new thread-local is declared
and every writer arms it with a TLS resolution it has already paid for:

* every writer notes a key `layout_key_may_be_nursery` admits BEFORE the entry
  becomes findable (rule 1) — the two insert wrappers, the in-borrow mask mint
  in `layout_note_slot`, and both per-object move hooks;
* a minor walks the log: a logged key in neither map is stale and drops, a
  present dead key is removed from both maps, a live key is re-logged only
  while still young, so a promoted owner leaves the log for good;
* a full prune keeps its whole-table walk (old owners DO die in a full trace)
  and rebuilds the log from the survivors it is already classifying;
* under `debug_assertions` the young prune re-derives the candidate set from
  the maps and panics on any young key the log does not name (rule 2);
* `note_walk` records logged/visited/kept/table_len per prune, so
  `[gc-young-log] table=gc.layout_tables` prints the skip and the tests read
  it back (rule 3).

The address filter is deliberately NOT rebuilt on a minor: the whole-table
walk that rebuilt it is what this removes, its `false` is the only
load-bearing answer, and a stale set bit is a false positive. The amortised
rebuild in `layout_addr_filter_add` and the full prune keep it selective.

Why this table pays where PerryTS#9754's scanners did not: a scanner keeps
`addr_is_minor_relevant`, true for `Longlived` by design, and cc allocates its
shape-key arrays longlived, so those logs never drain (`kept/logged` median
1.000, and `closure.dynamic_props` is a 2.56x regression there). A prune
excludes `Longlived` and `Old` both, and cc promotes every survivor after one
survival. Same mechanism, opposite sign, decided by the predicate.

`YoungLog::clear` loses its `#[cfg(test)]`: a prune that early-returns on the
emptiness proof must drop the log with it, or a workload that repeatedly fills
and empties the maps between collections accumulates stale keys for ever.

…rse than full

PerryTS#9754 gave four side tables a minor-scoped root scan. Measured per table on
the compiled claude-code TUI, three of them earn it and this one does not.

Both arms of a 3-turn 3300-character run on a quiet host (`[gc-young-log]`
rows, 273 and 272 minor cycles):

| table | skipped | verdict |
|---|---|---|
| `gc.layout_tables` | 99.0 % (366,347 visited of 36,938,896) | earns it |
| `object.descriptors` | 95.7 % | earns it |
| `object.transition_cache` | 83 % | earns it |
| `shapes.families+indices` | 80 % | earns it |
| **`closure.dynamic_props`** | **2.2-2.7 %** | **WORSE THAN FULL on 223/273 and 217/272 cycles** |

The cause is one predicate, and it is why the same technique lands so
differently on adjacent tables. A SCANNER's keep-test is
`addr_is_minor_relevant`, which returns true for `Longlived` BY DESIGN — a
longlived object can point at a young one — so the "relevant" set is close to
the whole table and the log never drains: `kept/logged` has median 1.000 here.
Multi-round re-logging then makes the young walk visit MORE entries than the
full walk it replaces. That is the same finding, and the same fix, as the
shape-cache young log dropped for skipping 0 % and costing 35 % more.

So every pass over this table is a full pass again.

The LOG ITSELF STAYS. `prune_dead_closure_side_table_owners_young` uses it,
and a PRUNE's predicate is not the scanner's: it asks who DIED, so it excludes
`Longlived` and `Old` both. That asymmetry is the whole point — the same
mechanism is a 99.0 % skip on one walk and a 2.2 % skip on another, decided
entirely by which predicate the walk keeps on. The full scanner rebuilds the
log from what it finds, so the prune's candidate set stays complete.

Rule 2 moves with it. The log-completeness re-derivation ran at the top of the
minor-scoped scanner; that walk is gone, and the prune is now the log's only
consumer, so the machine check that catches a writer publishing without arming
moves into the prune. Dropping the scanner without moving it would have
deleted the only guard on a log a prune still trusts — the failure would not
have been a slow walk but a dead owner's entries surviving in silence.

Not yet verified: this file has only been compiled with `debug_assertions`
OFF, so the moved `#[cfg(debug_assertions)]` call has not been type-checked
and the moved rule 2 has not been observed to fire.

`old_closure_entries_survive_a_minor_full_walk` failed on
`assert!(row.table_len >= 2)` with
`YoungLogWalk { partial: false, logged: 1, visited: 1, kept: 0, table_len: 1 }`.

It is the assertion, not the semantics, and the reason is a field-name
collision I carried over without checking.

**`table_len` means two different things in this one table's two walks.** The
young walk computed `props.len() + prototypes.len() + deleted.len()`; this
fixture's single owner appears in `props` AND `deleted_keys`, so it counted 2.
The full walk builds a deduped OWNER vec, so the same state counts 1. I moved
the assertion from one walk to the other and kept the old number.

**`kept=0` with `logged=1` is correct and is not a stale log entry.** On a
FULL row `logged` is set to `table_len` by construction (`logged: table_len,
visited: table_len`), so it means "one owner considered", not "one entry still
logged". The log after the walk holds `kept` entries, and 0 is right: an old
owner whose only value is a number and whose only other state is a deleted key
has nothing a minor can act on, so it must not be re-logged. That property is
now asserted (`kept < table_len`) instead of being an unexplained field in a
failure message.

Test-only. No product code changes.

The collision cuts the safe way for the verdict that motivated the revert, and
that is worth stating rather than leaving to be rechecked. `young_log_an.py`
derives `skipped = table_len * passes - visited` and flags `visited >
table_len * passes` as worse-than-full. In young mode `table_len` is the
INFLATED sum-of-three-maps, so it makes worse-than-full HARDER to trigger and
makes the reported skip percentage LARGER than the truth. The measured
`closure.dynamic_props` result — 2.2-2.7 % skipped, worse than full on 223/273
and 217/272 cycles — is therefore conservative in both directions, and the
real case for taking that table off its young walk is stronger, not weaker.